Skip to content

int64 over size_t for views - #1276

Merged
Simn merged 1 commit into
HaxeFoundation:masterfrom
Aidan63:no-sizet
Dec 14, 2025
Merged

int64 over size_t for views#1276
Simn merged 1 commit into
HaxeFoundation:masterfrom
Aidan63:no-sizet

Conversation

@Aidan63

@Aidan63 Aidan63 commented Dec 13, 2025

Copy link
Copy Markdown
Contributor

Seems like there were two problems here.

One is something only msvc flagged up, the get and set functions on the value type reference has an ambigious conversion if the function it calls accepts int64_t.

The other is that the type apple clang uses for size_t doesn't have a dynamic conversion, so I've just switched the last few size_t references to int64_t (I'll also update the haxe extern).

@tobil4sk

Copy link
Copy Markdown
Member

The other is that the type apple clang uses for size_t doesn't have a dynamic conversion, so I've just switched the last few size_t references to int64_t (I'll also update the haxe extern).

Would it not be possible to add the dynamic conversion for this type? size_t seems to be the more natural and correct type for this, and it matches the convention of the c++ std. It is also more portable across architectures.

@Aidan63

Aidan63 commented Dec 13, 2025

Copy link
Copy Markdown
Contributor Author

That was my initial thought and I do think it would be the better approach, but implementing that seems like it might be a bit tricker due to the varying size of size_t.

Many of the macros to add all the dynamic support for a type seem to except a fixed size, but to support size_t we'd need to add a bunch of extra conditionals for the size_t case. Or just go for the pessimistic approach and always box size_t as an int64, even if it's a 32bit build.

This should get the CI green for now atleast.

@Simn
Simn merged commit 4b2991f into HaxeFoundation:master Dec 14, 2025
120 checks passed
@Simn

Simn commented Dec 14, 2025

Copy link
Copy Markdown
Member

Huh... CI was green here, but after merging there's now this failure on 32bit linux latest:

unit.TestBytes
  test: FAILURE ........................................F...F............................................................................................................................
    line: 51, expected 66 but it is 67
    line: 57, expected 66 but it is 67

@Aidan63

Aidan63 commented Dec 14, 2025

Copy link
Copy Markdown
Contributor Author

Hmm, that is odd. I just did a HXCPP_M32 build of the haxe test suite locally in WSL and that passed fine. Those failing tests don't indicate anything either, just one of many charCodeAt and bytes get tests.

32bit linux haxe tests were also passed fine with the initial merge.

@Simn

Simn commented Dec 14, 2025

Copy link
Copy Markdown
Member

It's green after restarting the run. No idea what happened there, I guess we'll see if it happens again!

@Aidan63
Aidan63 deleted the no-sizet branch December 14, 2025 11:38
justin-espedal added a commit to Stencyl/hxcpp that referenced this pull request Apr 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants